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ABSTRACT 



Systems, methods and computer program products are pro- 
vided for testing whether Web content has been properly 
tailored by a transcoding proxy for display within various 
requesting pervasive computing devices. Simulated Hyper- 
Text Transfer Protocol (HTTP) requests are built using 
information from one or more data files. Each simulated 
request includes a Uniform Resource Locator (URL) thai 
identifies a location of Web content. Each simulated request 
also includes an HTTP header containing information about 
a respective pervasive computing device. Simulated HTTP 
requests are asynchronously issued to respective Web serv- 
ers identified in the respective HTTP requests. An HTTP 
response to each respective simulated HTTP request is 
received and includes Web content tailored for display 
within a respective pervasive computing device associated 
with the respective simulated HTTP request. Each HTTP 
response is then compared with an expected HTTP response. 
An HTTP response that does not compare favorably with an 
expected HTTP response can be saved for later analysis. 

39 Claims, 5 Drawing Sheets 
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SYSTEMS, METHODS AND COMPUTER / exact format of requests (HTTP requests) sent fromT^ 

PROGRAM PRODUCTS FOR VALIDATING ^browser to a Web server as well as the format of responses J 

WEB CONTENT TAILX>RED FOR DISPLAY ^(HlTRresponses) thatthe.Web.seryer returns to tbe br owser. j 

WITHIN PERVASIVE COMPUTING DEVICES Exemplary browsers for both Internet and intranet use 

5 include Netscape Navigator® (America Online, Inc., 22000 
AOL Way, Dulles, Va.) and Internet Explorer® (Microsoft 
Corporation, Redmond, Wash.). Browsers typically provide 



HELD OF THE INVENTION 



BACKGROUND OF THE INVENTION 



The present invention relates generally to the display of a graphical user interface for retrieving and viewing Web 

Web page content and, more particularly, to tailoring Web pages, applications, and other resources hosted by Internet/ 

content for display in client devices. intranet servers (hereinafter collectively referred to as "Web 

servers"). 

As is known to those skilled in this art, a Web page is 

The Internet is a worldwide decentralized network of conventionally formatted via a standard page description 

computers having the ability to communicate with each language such as HTML, which typically contains text and 

other. The Internet has gained broad recognition as a viable can reference graphics, sound, animation, and video data, 

medium for communicating and interacting across multiple HTML provides for basic document formatting and allows 

networks. The World-Wide Web (Web) was created in the a Web content provider to specify anchors or hypertext links 

early 1990's, and is comprised of server-hosting computers (typically manifested as highlighted text) to other Web 

(Web servers) connected to the Internet that have hypertext servers and files. When a user selects a particular hypertext 

documents (referred to as Web pages) stored therewithin. link, a browser reads and interprets an address, called a 

Web pages are accessible by client programs (e.g., Web Uniform Resource Locator (URL) associated with the link, 

browsers) utilizing the Hypertext Transfer Protocol (HTTP) connects the browser with a Web server at that address, and 

via a Transmission Control Protocol/Internet Protocol (TCP/ makes a request (e.g., an HTTP request) for the file identified 

IP) connection between a client-hosting device and a server- in the link. The Web server then sends the requested file to 

hosting device. While HTTP and Web pages are the preva- the Web client which the browser interprets and displays to 

lent forms for the Web, the Web itself refers to a wide range the user. 

of protocols including Secure Hypertext Transfer Protocol Many new electronic devices, such as personal digital 
(HTTPS), File Transfer Protocol (FTP), and Gopher, and assistants (PDAs), hand-held computers, Internet-ready 
Web content formats including plain text, HyperText phones, and WebTVs, are gaining access to the Internet 
Markup Language (HTML), Extensible Markup Language and/or to intranets as client devices. Electronic devices 
(XML), as well as image formats such as Graphics Inter- including, but not limited to, PDAs, cellular telephones, and 
change Format (GIF) and Joint Photographic Experts Group computing devices utilized within appliances and 
(JPEG). automobiles, are often collectively referred to as "pervasive" 
A Web site is conventionally a collection of Web pages computing devices. Many such pervasive computing devices 
and other files related to a particular subject that includes a utilize the Microsoft® Windows CE and 3Com Palm Corn- 
beginning file called a "home" page. A large Web site may puting® platforms. 

reside on a number of geographically-dispersed Web serv- Unfortunately, the capabilities of pervasive computing 
ers. The Web site of the International Business Machines devices to receive, process, store and display Internet con- 
Corporation (www.ibm.com), for example, consists of thou- tent may vary. For example, pervasive computing devices 
sands of Web pages and files spread out over various Web typically have displays that are small in size compared with 
servers in locations world-wide. desktop computer displays. As a result, content portions of 
An intranet is a private computer network conventionally a Web page, such as images and rendered HTML that may 
contained within an enterprise and that conventionally be otherwise displayable on a desktop computer display, 
includes one or more servers in communication with mul- 45 may not be displayable on a pervasive computing device 
tiple user computers. An intranet may be comprised of display unless some modifications to the images and/or text 
interlinked local area networks and may also use leased- (i.e., the content) are made. For example, a desktop com- 
lines in a wide-area network. An intranet may or may not puter display having an array of 1024 pixels by 768 pixels 
include connections to the outside Internet. Intranets con- may be able to display a large (e.g,, 2 megabyte), 24 bit per 
vcntionaUyutilize various Internet protocols and, in general, 50 pixel color image. A pervasive computing device with a 
often look like private versions of the Internet. An intranet display having an array of 120 pixels by 120 pixels, and with 
user conventionally accesses an intranet server via a browser the ability to display only about 3 bits per pixel, may ignore 
running locally on his/her computer. much of the image data. As a result the image may not be 
A Web (or intranet) server is a computer program displayed properly, if at all, via the pervasive computing 
(typically running on a computer) that serves requested Web ss device display unless the size of the image is transformed to 
pages and files. A Web client is a req uesti ng program the pervasive computing device's capabilities. Furthermore, 
associ ated w ith a uscr^S^rowse? is an exeinplary^ Webd ient^ some pervasive computing devices may not be capable of 
i^or use in requesSngWeb pages and files from Web~servers."A displaying certain image file types such as JPEG or GIF. 
Ca Web server waits for a Web client, such as a browser, to S Text fonts and sizes within Web content may also need to 
open-a.connection^and request a specific web page (or"file)~6o' be changed to permit the display thereof within a pervasive 
The Web server then sends'Xl;'opy'of~the~requested item, computing device display. Fiirthermore, common HTML 
closes the connection, and waits Jorjhe_next^connection._ ^ features such as frames and tables may not be displayable by 
^When a browser "iiiteracts with a Web server, the two ^ pervasive computing devices. Data within frames and tables 



^programs typically utilize HTTP. HTTP allows a browser to r may need to be removed and/or reformatted into other 
request a specific item, which the WetLserver-then-retums-65' configurations for proper display. In addition, performance 
and the browser renders. To ensure tfiat^browsers and_Web limitations of pervasive computing devices, such as memory 
server s can intero perate unambiguously, jl lTP defines then size and connection bandwidth, may also require changes to 
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Web page content for proper display thereof via a pervasive built iising information from one or more data.files. Each 

computing device. simulated request preferably includes- a^Uniform Resource 

It is known to take Web content that may not be properly <;Ixicator-(URL) that'idSTtifi^^ content. 

displayable via a pervasive computing device and "tailor" Each'simulatedTequest-also preferably includes an HTTP is^ 

the Web content into a format that is displayable. For S header containing information about a respective pervasive 

example, large, high resolution, color images can be trans- computing device. Exemplary pervasive computing device 

formed into small, black and white images that can be information included within an HTTP header may include, 

displayed within small, low resolution displays. The tailor- but is not limited to, an identification of a device's browser, 

ing of video, images, audio and text for display within a identification of a device's operating system, character- 

cUent device typically is referred to as "transcoding." Web lO istics of a device's display, and information about Web 

content transcoding is described in detail in pending U.S. content a devicejs^onfi^gured^ ^ 

patent apphcation Ser. No. 09/239,935 now U.S. Pat. No. Simulated «rnLr^^ests~are"issued to respective-^Web 3 

6,535,896 and Ser No. 09/240,137 now U.S. Pat. No. se^ersndentifiedin thTi^pectiveH^ 

6,457,030 which are assigned to Intemational Business respolnse to each re^ective"simulated HTTP requ^Pis 

Machines Corporation and which are incorporated herein by ^5 received_andjndudes Web content tailored for display) 

reference in their entirety. Web content transcoding is typi- within~a"respective pervasive computing device associated^ 

cally performed by a transcoding proxy associated with a (With the respective simulated HTTP request. ^Each~HTTP 

Web server. Products for transcoding Web content for dis- response is'th6n"compared with¥n~expccted HTTP response, 

play by a requesting client device are known. An exemplary An HTTP response that does not compare favorably with an 

transcoding product is "Cocoon^' available from the Apache '^^ expected HTTP response can be saved for later analysis. 

Server Foundation at http://java.apache.org. Cocoon is The present invention may facilitate determining whether 

described at httpVyjava.apache.org/cocoon/index.html which Web content is properly tailored for display within virtually 

is incorporated herein by reference. any type of client device having virtually any type of 

To perform Web content transcoding, a Web server and/or configuration without requiring that the actual device be 

transcoding proxy typically needs to know something about ^ used in the test. As a result, use of the present invention by 

a client device making an HTTP request. As is known to Web content providers may result in considerable time 

those of skill in the art, an HTTP header accompanies HTTP savings, cost savings, and higher quality program products, 
requests to a Web server. An HTTP header typically provides 

information about a requesting cfient device and browser BRIEF DESCRIPTION OF THE DRAWINGS 

Exemplary information provided within an HTTP header ^ schematically iUustrates the paths of an HTTP 

may include the size of a client device display, whether a corresponding HTTP response in a chent-server 

cUent device display is a color display or a monochromaUc environment including a transcoding proxy that tailors Web 

display, an identification of the chent device browser, and an ^^^^^nt for display within requesting client devices, 

identification of the client device operating system. „_ _ . „ ^ . i, . c i j 

. , 35 FIG. 2 is a flow chart illustrating operations for vahdating 

Pervasive computing devices with vanous browsers and t,^scoded Web content provided in response to a chent 

configurations are being developed and introduced to market according to the present invention, 

at a rapid pace. Given the variety of new pervasive com- ^ . , , j a u . n * * c 

puting devices, it may be difScult for Web content pubhshers ^ l^^' ^ ^^^^^^^ illustrat^mg operations for 

to tailor content so as to be adequately displayable within ^'^jl^^^S '"^TLt E ^ ^ ^ JfTTP requests and 

many different devices. As a result, a need exists for quickly '° transcoded Web content provided m response to 

and easily verifying that Web content taHoring is being ^^^^^^^^ P^^^^°^ 

performed correctly for each type of client device making an FIG. 4 is a schematic illustration of a data processing 

HTTP request. Currently, testing whether or not Web content system for carrying out operations of the present invention, 

tailoring is being performed properly is done by making FIG, 5 is a schematic iUustration of a data processing 

HTTP requests with each actual client device. system in communication with a pluraUty of Web servers 

Unfortunately, the ability to test Web content tailoring with and transcoding proxies, wherein the data processing system 

many different client devices may be expensive and time is configured to build and send a pluraUty of HTTP requests 

consuming, and may be technically in feasible to analytically and to receive a corresponding plurality of respective HTTP 

validate responses. responses according to the present invention. 

SUMMARY OF THE INVENTION DETAILED DESCRIPTION OF THE 
In view of the above discussion, it is an object of the INVENTION 
present invention to provide systems, methods and computer The present invention now is described more fully here- 
program products for simulating different chent devices 55 inafter with reference to the accompanying drawings, in 
running on various software platforms to ensure that Web which preferred embodiments of the invention are shown, 
page content tailoring is performed correctly. This invention may, however, be embodied in many different 
It is another object of the present invention to facifitate the forms and should not be construed as Umited to the embodi- 
display of Web pages via pervasive computing devices that ments set forth herein; rather, these embodiments are pro- 
may have smaller displays and various performance limita- 60 vided so that this disclosure wiU be thorough and complete, 
tions as compared with desktop computing devices. and will fully convey the scope of the invention to those 
These and other objects of the present invention are skilled in the art. Like numbers refer to like elements 

provided by systems, methods and computer program prod- throughout. 

ucts for testing (i.e., validating) whether Web content has ,As ^ will be ap prcciate d_by_one_of_skilLin the art , Hhe ) 

been properly tailored by a transcoding proxy for display 65 present invention may be embodied as a method, data^ 

within various requesting pervasive computing devices. pro.cessing_systeEn,_^i^_comp^tei_pj^gj^ 

sSirmUated HyperText TrlirSfer Pfoto^ Accordingly, the present invention may take the form of an 
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entirely hardware embodiment, an entirely software embodi- response 25 containing the requestedW eb content i s sent to 

ment or an embodiment combiiiing software and hardware the client device 10 via (jhc^t ranscq din g proxy 3 0. The 

aspects. Furthermore, the present invention may take the transcoding proxy 30 tailors the Web content within the 

form of a computer program product on a computer-usable HTTP response 25 producing a "modified" HTTP response 
storage medium having computer-usable program code 5 25*. The taUored Web content in the modified HTTP 

means embodied in the medium. Any suitable computer response 25' is readerablc within the client device 10. It is 

readable medium may be utilized including hard disks, understood that a transcoding proxy 30 may be implemented 

CD-ROMs, optical storage devices, or magnetic storage as software^codei^iding^athii^^ 20, as 

devices. ^softwarerade external t^the HTTP server jO, suc h as within S 

Computer program code for carrying out operations of the /a jrcwall~orj omc combinati on there of."^ 

present invention is preferably written in an object oriented The present invention provides methods, systems and 

programming language such as(JS^®i~Smalltalk or C++. computer program products for validating transcoded Web 

However, the computer program^code^for carrying out content provided in response to HTTP requests without 

operations of the present invention may also be written in requiring the actual client devices to make the HTTP 
conventional procedural programming languages, such as 15 requests. According to the present invention, multiple client 

the "C programming language, or in a functional (or fourth requests can be simulated by a single computer in commu- 

generation) programming language such as Lisp, SML, or nication with one or more Web servers, such as via the 

Forth. Internet, an intranet, or other communications network. 

The present invention is described below with reference Referring now to FIG. 2, operations for validating 

to block diagrams and/or flowchart illustrations of methods, transcoded Web content according to the present invention 

apparatus (systems) and computer program products accord- are illustrated. A plurality of simulated HTTP requests are 

ing to an embodiment of the invention. It is understood that built (Block 100) by a computing device using .various data 

each block of the block diagrams and/or flowchart files. Each simulated HTTP request includes a Uniform 

illustrations, and combinations of blocks in the block dia- Resource Locator (URL) that identifies the location of 

grams and/or flowchart illustrations, can be implemented by Specific Web content to be displayed within a requesting 

mmp^ite r nro^ram instruction s. These computer program client device. Each HTTP request also includes an HTTP 

instructions may be provided to a processor of a general header that contains information about a requesting client 

,£uroosecomputer, special purpose computer, or other pro- device and that specifies what types of Web content the 

grammatile data processing apparatus to produce a machine, client device is prepared to handle. As is known to those of 

such that the instmctions, which execute via the processor of skill in the art, HTTP headers communicate information that 

the computer or olhe\» programmable data processing Web servers and browsers use to define the type of data that 

apparatus, create means for implementing the functions is being exchanged therebetween. 

specified in the block diagram and/or flowchart block or Simultaneous HTTP requests are preferably issued asyn- 

blocks. chronously to Web servers identified in the respective HTTP 

These computer program instructions may also be stored requests (Block 110, FIG. 2). Preferably, a computing device 
in a computer-readable memory that can direct a computer for implementing the present invention implements the 
or other programmable data processing apparatus to function HTTP "GET" method for each of the respective HTTP 
in a particular manner, such that the instructions stored in the requests. The HTTP *'GET" method, which is well under- 
computer-readable memory produce an article of manufac- stood by those skilled in the art, is described in detail in 
ture including instruction means which implement the func- "Hypertext Transfer Protocol — HTTP/1.1", Network Work- 
tion specified in the block diagram and/or flowchart block or ing Group Request for Comments 2068, January 1997. 
blocks. An HTTP response to each HTTP request is preferably 

The computer program instructions may also be loaded stored (Block 120, FIG. 2). Each HTTP response includes an 
onto a computer or other programmable data processing ^5 HTTP header and Web content that has been tailored for 

apparatus to cause a series of operational steps to be per- display within a client device identified as making the 

formed on the computer or other programmable apparatus to corresponding HTTP request. Each received HTTP response 

produce a computer implemented process such that the is compared with an expected HTTP response (Block 130, 

instructions which execute on the computer or other pro- FIG. 2). HTTP responses not matching their respective 
grammable apparatus provide steps for implementing the 50 expected responses are preferably saved for later analysis, 

functions specified in the block diagrams and/or flowchart As illustrated in FIG. 3, multiple simulated HTTP 

block or blocks. requests can be built and issued simultaneously and asyn- 

Ref erring now to FIG. 1, the paths of an HTTP request chronously up to "n^' iterations, where n can be virtually any 

and corresponding HTTP response in a client-server value. Simultaneous building and issuance of multiple, 
relationship, including a transcoding proxy that tailors Web 55 simulated HTTP requests are schematically represented by 

content, are_schematically^ illustrated. A client d evice 10 operations 102-1 through 130-1, operations 102-2 through 
makcs_MfHTTP;re^uest4.5To^ Web content from an Hi TP ^ 130-2, and operations 102-n through 130-n. A detailed 

,( i.e., Web ) serv er 20 } The protocol for HTTP requests and description of operations 102-1 through 130-1 is provided 

responses are described in detail in "Hypertext Transfer below and it is understood that these operations are the same 

Protocol — HTTP/1.1", Network Working Group Request for any of the n iterations. 

for Comments 2068, January 1997, which is incorporated For each HTTP request, a computing device implement- 
herein by reference in its entirety. ing the present invention preferably selects a URL defining 
In the illustrated_clicnt;server _relationshi p, the HTTP Web content to be fetched firom a data file (Block 102-1). 
request 15^ passes / through a transcoding proxy 30 _and is Similarly, HTTP header fields are preferably selected from 
^^godifiedjy the transcoding proxy 30/as would be under- 65 a data file (Block 104-1). A selected URL and selected HTTP 
stood'by one of skill in the art. The modified HTTP request header fields are then combined to bufld each respective 
15' is processed by the HTTP server 20 and an HTTP HTTP request (Block 106-1). Each built HTTP request is 
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then issued to the Web server identified in the built HTTP altered by the one or more application programs 603a, 6036 

request (Block 110-1). or the operating system 602, either individually or in com- 

After a response to an HTTP request is received and binalion. For obtaining input from a user, the operating 

stored (Block 120-1), a decision is made whether to build ^V^^V^ ^ application programs 603a 603ft, or a 
another HTTP request (Block 122-1). Once a decision is S combinalioa thereof may uldize user mput devices 605 

made not to build another HTTP request, each returned "^f I"?"' 'P^V. '"'^^'f ^ ? P^^f "°S d^vce 606 

ut™, . J * J and a keyboard 607 or other input devices known to those of 

HTTP response is compared with an expected response ^ ^ 

(Block 130-1). Preferably, each failed response is stored for r. r • ' . i-t.^ j . • * ^nnc 

later analysis to determine why the Web content was not Refemngnowto FIG. 5 a data processing system 600 for 
properly transcoded. lo '^'^'^'^S °"! °Pf "i^ons of present invention is lUustrated 

^ in communication with a plurality of Web servers 702 and 

-Die decision to build another HTTP request may depend transcoding proxies 704 via a communications network, 

on the Web content returned m an HTTP request For such as the Internet and/or an intranet 701. In the iUustrated 

example, if Web content within an HTTP response contains embodiment, one or more Web servers 702 may utilize a 

images, the present invention may build respective HTTP transcoding proxy 704 that is configured to tailor Web 

requests for each image. Accordingly, the methods of the content as described above. The data processing system 600 

preseiit invention may be recursive and the iterative steps of ^ configured as described above to simulate HTTP requests 

FIG. 3 may continue until all types of files within a Web f,^^ ^i^jtiple pervasive computing devices without requir- 

page are requested. As a result, the tailoring of content of an ^^^g ^^^^^^ pervasive computing devices to make the HTTP 

entire Web site can be validated via a data processing system requests. The data processing system 600 builds and issues 

implemenung the present invention. multiple HTTP requests, wherein each HTTP request 

Exemplary information about a requesting client device includes an HTTP header that contains information about a 

that is provided within HTTP header fields may include, but respective pervasive client device/browser configuration, 

is not limited to, an identification of a browser running on These HTTP requests can then be sent to designated Web 

the client device (e.g., user-agent), an identification of the servers as asynchronous, parallel requests, 
client device operating system, an identification of charac- j^^ ^^^^ processing system 600 is configured as described 

teristics of the client device display, and an identification of above to receive, via the Internet and/or intranet 701, HTTP 

Web content the client device is configured to display. responses to the HTTP requests and to compare the HTTP 

Exemplary client device display characteristics include, but responses with expected HTTP responses. Preferably, the 

are not limited to, display size and whether or not the display data processing system 600 is configured to store HTTP 

is a color display or a monochromatic display. responses and then perform HTTP response comparison 

Referring now to FIG. 4, a data processing system 600 for operations as a batch process. Accordingly, the present 

carrying out operations of the present invention are sche- invention provides an efficient, cost effective way of more 

matically illustrated. As seen in FIG. 4, a data processor 601 thoroughly testing Web content tailoring for multiple per- 
may have an operating system 602 resident therein with 35 vasive computing devices without requiring the actual per- 

various application programs 603 for carrying out operations vasive computing devices. 

of the present invention and that run on the operating system xhe foregoing is illustrative of the present invention and 

602. In particular, an HTTP Request Builder application is not to be construed as limiting thereof. Although a few 

603a is provided to carry out the HTTP request building and exemplary embodiments of this invention have been 

issuing operations set forth in Blocks 100 and 110 of FIG. described, those skilled in the art will readily appreciate that 

2 and Blocks 100 through 122-1 of FIG. 3. A Response ^any modifications are possible in the exemplary embodi- 

Comparator appUcation 603b is provided to carry out opera- ments without materially departing from the novel teachings 

tions for comparing received HTTP responses with expected and advantages of this invention. Accordingly, all such 

responses set forth in Block 130 of FIG. 2 and Block 130-1 modifications are intended to be included within the scope of 
of FIG. 3. ^5 this invention as defined in the claims. In the claims, 

Still referring to FIG. 4, the applications 603a^ 6036 are means-plus-function clause are intended to cover the struc- 

in communication with data storage 609, which may be tures described herein as performing the recited function and 

either external or internal data storage, or a combination of not only structural equivalents but also equivalent structures, 

external and internal data storage. The HlTP Request Therefore, it is to be understood that the foregoing is 
Builder application 603/2 is cnnfi paired to read H I'l V nca'He r 50 illustrative of the present invention and is not to be construed 

elements and URLs from data storage 609. and buna and as hmited to the specific embodiments disclosed, and that 

JssueJlTTP requests as set forth jn qinrVg inn -inH nc} nf modifications to the disclosed embodiments, as well as other 
FIG. 2 and Blocks 100 through 122-1 of FIG. 3. Th?*' embodiments, are intended to be included within the scope 

Response Comparator application 6036 is configured to of the appended claims. The invention is defined by the 
compare received HTTP responses with expected responses 55 following claims, with equivalents of the claims to be 

set forth in Block 130 of FIG. 2 and Block 130-1 of FIG. 3. included therein. . ' . 

In addition, data storage 609 may be utilized to store built lliat which is claimed is: 



HTTP requests and to store received HTTP responses and 1. Ametiiod of vabdahng V^eb content tailored for display 

for implementing the various method steps of the present within a pervasive computing device in response to a 

invention as one or more batch processes. simulated request from the pervasive computing device 

As would be understood by one of skill in the art, the generated by a data processing system that is not the 

processor 601 displays information on a display device 604. pervasive computing device, the method comprising the 

The display device 604 has a plurality of picture elements following steps: 

(collectively referred to as a screen) which may define the building a si mulated H yperText Transfer Protocol 

appearance of a graphical user interface (GUI) displayed on 65 (HTTP) request ol a pervasive 'tDluputihg dev^rce' Via a 

the display device 604. The contents of the screen and, separate data processing system that is not the perva- 

therefore, the appearance of a GUI, may be controlled or sive computing device, wherein the simulated HTTP 
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request includes a Uniform Resource Locator (URL) 
that ideatifies a location of Web content, and wherein 
the simulated HTTP request includes an HTTP header 
that contains information about the pervasive comput- 
ing device; 

issuing the simulated HTTP request from the data pro- 
cessing system independently of the pervasive comput- 
ing device to a Web server identified in the simulated 
HTTP request; 

receiving at the data processing system independently of 
the pervasive computing device an HTTP response 
from the Web server, wherein the HTTP response 
includes Web content tailored for display within the 
pervasive computing device by a transcoding proxy 
adapted to tailor Web content for display within per- 
vasive computing devices; and 

comparing the received HTTP response with an expected 
response. 

2. The method according to claim 1 wherein the pervasive 
computing device information includes at least one of an 
identification of a browser running on the pervasive com- 
puting device, an identification of an operating system 
running on the pervasive computing device, an identification 
of characteristics of a display for the pervasive computing 
device, and an identification of Web content the pervasive 
computing device is configured to display. 

3. The method according to claim 1 further comprising the 
step of storing the HTTP response received in response to 
the simulated HTTP request. 

4. The method according to claim 1 further wherein the 
step of comparing the received HTTP response with an 
expected HTTP response comprises the step of storing the 
received HTTP response if the received H i'l F response does 
not match the expected HTTP response. 

5. The method according to claim 1 wherein the step of 
building a simulated HTTP request via the data processing 
system comprises: 

building a plurality of simulated HTTP requests from a 
respective plurality of pervasive computing devices via 
the data processing system, wherein each simulated 
HTTP request includes a Uniform Resource Locator 
(URL) that identifies a location of Web content, and 
wherein each simulated HTTP request includes an 
HTTP header that contains information about a respec- 
tive pervasive computing device; and 

storing the pluraUty of simulated HTTP requests. 

6. The method according to claim 5 wherein the step of 
issuing the simulated HTTP request via the data processing 
system to a Web server identified in the simulated HTTP 
request comprises asynchronously issuing the plurality of 
simulated HTTP requests via the data processing system to 
Web servers identified in each respective simulated HTTP 
request. 

7. The method according to claim 5 wherein the step of 
building a plurality of simulated HTTP requests via the data 
processing system comprises retrieving HTTP header fields 
and URLs from respective data files. 

8. The method according to claim 5 wherein the step of 
comparing the received HTTP response with an expected 
HTTP response comprises comparing each received HTTP 
response with an expected HTTP response for a pervasive 
computing device associated with each respective simulated 
HTTP request. 

9. A method of validating Web content tailored for display 
within a plurality of pervasive computing devices in 
response to simulated requests from the pervasive comput- 



ing devices generated by a data processing system that is not 
one of the pervasive computing devices, the method com- 
prising the following steps: 

building a plurality of simulated HyperText Transfer 
Protocol PITTP) requests for one or more pervasive 
computing devices via a separate data processing sys- 
tem that is not the one or more pervasive computing 
devices, wherein each simulated HTTP request 
includes a Uniform Resource Locator (URL) that iden- 
tifies a location of Web content, and wherein each 
simulated HTTP request includes an HTTP header that 
contains information about a respective pervasive com- 
puting device; 
asynchronously issuing each simulated HTTP request 
from the data processing system independently of the 
one or more pervasive computing devices to a Web 
server identified in each respective simulated HTTP 
request; 

receiving at the data processing system independently of 
the one or more pervasive computing devices an HTTP 
response to each respective simulated HTTP request, 
wherein each HTTP response includes Web content 
tailored for display within a pervasive computing 
device identified within a respective simulated HTTP 
request; and 

comparing each received HTTP response with an 
expected HTTP response for a pervasive computing 
device specified in each respective simulated HTTP 
request. 

10, The method according to claim 9 wherein pervasive 
computing device information within each simulated HTTP 
request includes at least one of an identification of a browser 
running on a pervasive computing device, an identification 
of an operating system running on a pervasive computing 
device, an identification of characteristics of a pervasive 
computing device display, and an identification of Web 
content a pervasive computing device is configured to 
display. 

U. The method according to claim 9 further comprising 
40 the step of storing the HTTP responses received in response 
to the simulated HTTP requests. 

12. The method according to claim 9 wherein the step of 
comparing each received HTTP response with a respective 
expected HTTP response comprises storing the received 
HTTP response if the received HTTP response does not 
match the expected HTTP response. 

13. The method according to claim 9 wherein the step of 
building a plurality of simulated HTTP requests comprises 
retrieving HTTP header fields and URLs from respective 
data files. 

14. A system that vafidates Web content tailored for 
display within a pervasive computing device in response to 
a simulated request from the pervasive computing device 
generated by a data processing system that is not the 

55 pervasive computing device, comprising: 

means for building a simulated HyperText Transfer Pro- 
tocol (HTTP) request of a pervasive computing device 
independently of the pervasive computing device, 
wherein the simulated HTTP request includes a Uni- 
form Resource Locator (URL) that identifies a location 
of Web content, and wherein the simulated HTTP 
request includes an HTTP header that contains infor- 
mation about the pervasive computing device; 
means for issuing the simulated HTTP request firom the 
data processing system independently of the pervasive 
computing device to a Web server identified in the 
simulated HTTP request; 
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means for receiving at the data processing system inde- 
pendently of the pervasive computing device an HTTP 
response from the Web server, wherein the HTTP 
response includes Web content tailored for display 
within the pervasive computing device by a transcoding 
proxy adapted to tailor Web content for display within 
pervasive computing devices; and 

means for comparing the received HTTP response with an 
expected HTTP response. 

15. The system according to claim 14 wherein the per- 
vasive computing device information includes at least one of 
an identification of a browser running on the pervasive 
computing device, an identification of an operating system 
running on the pervasive computing device, an identification 
of characteristics of a display for the pervasive computing 
device, and an identification of Web content the pervasive 
computing device is configured to display. 

16. The system according to claim 14 wherein the means 
for receiving an HTTP response from the Web server com- 
prises means for storing the HTTP response. 

17. The system according to claim 14 wherein the means 
for comparing the received HTTP response with an expected 
HTTP response comprises means for storing the received 
HTTP response if the received HTTP response does not 
match the expected HTTP response. 

18. The system according to claim 14 wherein the means 
for building a simulated HTTP request comprises: 

means for building a plurality of simulated HTTP requests 
from a respective plurality of pervasive computing 
devices, wherein each simulated HTTP request 
includes a Uniform Resource Locator (URL) that iden- 
tifies a location of Web content, and wherein each 
simulated HTTP request includes an HTTP header that 
contains information about a respective pervasive com- 
puting device; and 

means for storing the plurality of simulated HTTP 
requests. 

19. The system according to claim 18 wherein the means 
for issuing the simulated HTTP request via the data pro- 
cessing system to a Web server identified in the simulated 
HTTP request comprises means for asynchronously issuing 
the plurality of simulated HTTP requests to Web servers 
identified in each respective simulated HTTP request. 

20. The system according to claim 18 wherein the means 
for building a plurality of simulated HTTP requests via the 
data processing system comprises means for retrieving 
HTTP header fields and URLs from respective data files. 

21. The system according to claim 18 wherein the means 
for comparing the received HTTP response with an expected 
HTTP response comprises means for comparing each 
received HTTP response with an expected HTTP response 
for a pervasive computing device associated with each 
respective simulated HTTP request. 

22. A system that validates Web content tailored for 
display within a plurality of pervasive computing devices in 
response to simulated requests from the pervasive comput- 
ing devices generated by a data processing system that is not 
one of the pervasive computing devices, comprising: 

means for building a plurality of simulated HyperText 
Transfer Protocol (HTTP) requests of one or more 
pervasive computing devices independently of the one 
or more pervasive computing devices, wherein each 
simulated HTTP request includes a Uniform Resource 
Locator (URL) that identifies a location of Web 
content, and wherein each simulated HTTP request 
includes an HTTP header that contains information 
about a respective pervasive computing device; 
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means for asynchronously issuing independently of the 
one or more pervasive computing devices each simu- 
lated HTTP request from the data processing system to 
a Web server identified in each respective simulated 
HTTP request; 

means for receiving independently of the one or more 
pervasive computing devices an HTTP response to 
each respective simulated HTTP request, wherein each 
HTTP response includes Web content tailored for dis- 
play within a pervasive computing device identified 
within a respective simulated HTTP request; and 

means for comparing each received HTTP response with 
an expected HTTP response for a pervasive computing 
device specified in each respective simulated HTTP 
request. 

23. The system according to claim 22 wherein pervasive 
computing device information within each simulated HTTP 
request includes at least one of an identification of a browser 
running on a pervasive computing device, an identification 
of an operating system running on a pervasive computing 
device, an identification of characteristics of a pervasive 
computing device display, and an identification of Web 
content a pervasive computing device is configured to 
display. 

24. The system according to claim 22 wherein the means 
for receiving an HTTP response to each respective simulated 
HTTP request comprises means for storing the HTTP 
responses. 

25. The system according to claim 22 wherein the means 
for comparing each received HTTP response with a respec- 
tive expected HTTP response comprises means for storing 
the received HTTP response if the received HTTP response 
does not match the expected HTTP response. 

26. Th& system according to claim 22 wherein the means 
for building a plurality of simulated HTTP requests com- 
prises means for retrieving HTTP header fields and URLs 
from respective data files. 

27. A computer program product for validating Web 
content tailored for display within a pervasive computing 
device in response to a simulated request from the pervasive 
computing device generated by a data processing system 
that is not the pervasive computing device, the computer 
program product comprising a computer usable storage 
medium having computer readable program code means 
embodied in the medium, the computer readable program 
code means comprising: 

computer readable program code means for building a 
simulated HyperText Transfer Protocol (HTTP) request 
of a pervasive computing device independently of the 
pervasive computing device, wherein the simulated 
HTTP request includes a Uniform Resource Locator 
(URL) that identifies a location of Web content, and 
wherein the simulated HTTP request includes an HTTP 
header that contains information about the pervasive 
computing device; 

computer readable program code means for issuing inde- 
pendently of the pervasive computing device the simu- 
lated HTTP request from the data processing system to 
a Web server idenfified in the simulated HTTP request; 

computer readable program code means for receiving 
independently of the pervasive computing device at the 
data processing system an HTTP response from the 
Web server, wherein the HTTP response includes Web 
content tailored for display within the pervasive com- 
puting device by a transcoding proxy adapted to tailor 
Web content for display within pervasive computing 
devices; and 
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computer readable program code means for comparing 
the received HTTP response with an expected HTTP 
response. 

28. The computer program product according to claim 27 
wherein the pervasive computing device information 
includes at least one of an identification of a browser running 
on the pervasive computing device, an identification of an 
operating system running on the pervasive computing 
device, an identification of characteristics of a display for the 
pervasive computing device, and an identification of Web 
content the pervasive computing device is configured to 
display. 

29. The computer program product according to claim 27 
wherein the computer readable program code means for 
receiving an HTTP response from the Web server comprises 
computer readable program code means for storing the 
HTTP response. 

30. The computer program product according to claim 27 
wherein the computer readable program code means for 
comparing the received HTTP response with an expected 
HTTP response comprises computer readable program code 
means for storing the received HTTP response if the 
received HTTP response does not match the expected HTTP 
response. 

31. The computer program product according to claim 27 
wherein the computer readable program code means for 
building a simulated HTTP request comprises: 

computer readable program code means for building a 
plurality of simulated HTTP requests from a respective 
plurahty of pervasive computing devices, wherein each 
simulated HTTP request includes a Uniform Resource 
Locator (URL) that identifies a location of Web 
content, and wherein each simulated HTTP request 
includes an HTTP header that contains information 
about a respective pervasive computing device; and 

computer readable program code means for storing the 
plurahty of simulated HTTP requests. 

32. The computer program product according to claim 31 
wherein the computer readable program code means for 
issuing the simulated HTTP request via the data processing 
system to a Web server identified in the simulated HTTP 
request comprises computer readable program code means 
for asynchronously issuing the plurality of simulated HTTP 
requests to Web servers identified in each respective simu- 
lated HTTP request. 

33. The computer program product according to claim 31 
wherein the computer readable program code means for 
building a plurality of simulated HTTP requests via the data 
processing system comprises computer readable program 
code means for retrieving HTTP header fields and URLs 
from respective data files. 

34. The computer program product according to claim 31 
wherein the computer readable program code means for 
comparing the received HTTP response with an expected 
HTTP response comprises computer readable program code 
means for comparing each received HTTP response with ao 
expected HTTP response for a pervasive computing device 
associated with each respective simulated HTTP request, 

35. A computer program product that validates Web 
content tailored for display within a plurality of pervasive 
computing devices in response to simulated requests from 
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the pervasive compudng devices generated by a data pro- 
cessing system that is not one of the pervasive computing 
devices, the computer program product comprising a com- 
puter usable storage medium having computer readable 
5 program code means embodied in the medium, the computer 
readable program code means comprising: 

computer readable program code means for building a 
plurality of simulated HyperText Transfer Protocol 
(HTTP) requests of one or more pervasive computing 
10 devices independently of the one or more pervasive 
computing devices, wherein each simulated HTTP 
request mcludes a Uniform Resource Locator (URL) 
that identifies a location of Web content, and wherein 
each simulated HTTP request includes an HTTP header 
15 that contains information about a respective pervasive 
computing device; 
computer readable program code means for asynchro- 
nously issuing independently of the one or more per- 
vasive computing devices each simulated HTTP 
^0 request from the data processing system to a Web 
server identified in each respective simulated HTTP 
request; 

computer readable program code means for receiving 
independently of the one or more pervasive computing 
devices an HTTP response to each respective simulated 
HTTP request, wherein each HTTP response includes 
Web content tailored for display within a pervasive 
computing device identified within a respective simu- 
lated HTTP request; and 

computer readable program code means for comparing 
each received HTTP response with an expected HTTP 
response for a pervasive computing device specified in 
each respective simulated HTTP request. 

36. The computer program product according to claim 35 
wherein pervasive computing device information within 
each simulated HTTP request includes at least one of an 
identification of a browser running on a pervasive comput- 
ing device, an identification of an operating system nmning 
on a pervasive computing device, an identification of char- 
acteristics of a pervasive computing device display, and an 
identification of Web content a pervasive computing device 
is configured to display. 

37. The computer program product according to claim 35 
wherein the computer readable program code means for 
receiving an HTTP response to each respective simulated 
HTTP request comprises computer readable program code 
means for storing the HTTP responses. 

38. The computer program product according to claim 35 
wherein the computer readable program code means for 
comparing each received HTTP response with a respective 
expected HTTP response comprises computer readable pro- 
gram code means for storing the received HTTP response if 
the received HTTP response does not match the expected 
HTTP response. 

39. The computer program product according to claim 35 
wherein the computer readable program code means for 
building a plurality of simulated HTTP requests comprises 
computer readable program code means for retrieving HTTP 
header fields and URLs from respective data files. 

60 
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